As the Internet expands, diverse network services and advanced multimedia communication systems emerge quickly. Due to the fact that real-time services are sensitive to features such as network transmission delay and time jitter, such services will be affected severely when there is any outburst of File Transfer Protocol (FTP) or Hyper Text Transfer Protocol (HTTP) service involving image files. In addition, it is difficult to reliably transmit key services that must be assured through the existing network since multimedia services occupy bandwidth heavily. Therefore, diverse Quality of Service (QoS) techniques emerge as the times require. Internet Engineering Task Force (IETF) has proposed many service models and mechanisms to meet the demand for QoS.
A wide range of portal-based applications and services as well as broadband multimedia services have become an important content in broadband operation, including providing rich Video/Audio streams, Video on Demand (VOD), video multicasting, multimedia interaction, and network games with high bandwidth requirements for common residential users, providing videoconference, remote education, Virtual Private Networks (VPNs), QoS assured data private lines, and IP Hotels, etc., for commercial users.
Operators and enterprise users have high acknowledgement to Ethernet technique and end-to-end Ethernet technique. Ethernet technique has become one of the major techniques in construction of unified networks and Metropolitan Area Networks (MANs), and Ethernet services have a good prospect in the future market. In view of the above situation, in the packet-based network architecture (i.e., Next Generation Network (NGN)) proposed in Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN) by European Telecommunications Standards Institute (ETSI), a Resource Admission Control Subsystem (RACS) is introduced between application layer and transport layer to manage resources in the bearer network centrally; in addition, policy-based control is provided, so that QoS of the bearer network and Network Address Translation (NAT), etc., are accessed and controlled via RACS.
The RACS architecture defined in TISPAN is shown in FIG. 1. Wherein, the RACS mainly includes: an Application Function (AF) 110, a Service-based Policy Decision Function (SPDF) 120, a Border Gateway Function (BGF) 130, an Access-Resource and Admission Control Function (A-RACF) 140, and a Resource Control Enforcement Function (RCEF) 150. The relationship and interfaces between respective functions in the RACS are also shown in FIG. 1.
Wherein, the control of Network Address and Port Translation (NAPT) is mainly performed by means of interaction among AF 110, SPDF 120, and BGF 130; the A-RACF 140 and RCEF 150 are mainly used for control of QoS resources on access layer.
In the foresaid RACS architecture, relevant resources have to be revoked once a bearer path is released or an installed policy has become invalid. The resource revoke process can be initiated by a Network Attachment Subsystem (NASS) or RCEF in the prior art.
Referring to FIG. 2, the main process of initiating a resource revoking by NASS in the prior art is as follows:
(201) the NASS decides to release a bearer path, e.g., the customer premise equipment requests the NASS to release the bearer path.
(202) The NASS notifies an A-RACF to remove the access information by sending an IP-Connectivity-Release-Indication to notify the A-RACF that the access network information has become invalid.
(203) The A-RACF requests to revoke all relevant resources by sending a Revoke Reservation request to notify an SPDF to revoke resource reservation.
(204) An SPDF notifies an AF to revoke resource reservation by sending a Revoke Reservation request.
(205) The A-RACF checks whether to revoke the policy installed for an RCEF; if so (i.e., the policy has been installed for RCEF), it executes step (206); otherwise it terminates the process.
(206) The A-RACF notifies the RCEF to revoke the policy by sending an RCEF Service Resource Release request.
(207) The RCEF revokes the policy, and returns the result by sending an RCEF Service Resource Release Acknowledgement.
Referring to FIG. 3, the main process of initiating resource revoke by RCEF in the prior art is as follows:
(301) the RCEF determines an installed policy has become invalid (e.g., due to an internal failure).
(302) The RCEF notifies A-RACF that the policy has become invalid with an Event Notify event.
(303) The A-RACF requests to revoke all relevant resources by sending a Revoke Reservation request to the SPDF to notify SPDF to revoke resource reservation.
(304) The SPDF notifies the AF to revoke resource reservation by sending a Revoke Reservation request.
According to the above two resource revoke processes: in the prior RACS architecture, if a call has requested BGF for service resources (e.g., NAT) but NASS or RCEF initiates resource revoke for some reason, the service resources allocated by BGF will not be revoked, resulting in waste of network resources.